home *** CD-ROM | disk | FTP | other *** search
-
-
- CURRENT_MEETING_REPORT_
-
- Reported by Guy Almes/ Rice
-
- MINUTES
-
-
- 1. Guy Almes and Yakov Rekhter led a review of progress to date,
- including the conditional acceptance of the BGP Protocol document
- as a Proposed Internet Standard. (By mid-May, the BGP Protocol
- document was approved by the IESG and forwarded to the IAB for
- approval as a Proposed Internet Standard. Both the BGP Protocol
- and the BGP Usage documents will soon be published.) Changes to
- the protocol since the Florida State meeting were discussed.
- 2. Yakov Rekhter led a discussion of BGP stability. It is possible to
- configure a pair of neighboring ASes with incompatible routing
- policies such that an oscillation sets in. Yakov sketched the
- problem in detail and showed how the oscillation could be
- automatically detected.
- 3. Steve Willis led a discussion of a proposed MIB for BGP. This
- discussion resulted both in a better proposed MIB and a deeper
- understanding within the group of a number of BGP issues. A key
- issue was whether the BGP MIB should reflect the BGP information
- received from neighbors, actually used locally, or advertised to
- neighbors. Steve will follow up with an Internet Draft describing
- the MIB.
- 4. Guy Almes led a discussion of the use of BGP in monitoring the
- health of global Inter-AS routing. In the course of the
- discussion, the implications of External vs Internal BGP, even in
- the case of the monitoring station not being involved in routing,
- were shown to be important. The use of BGP for monitoring will
- allow a number of monitoring applications that would be totally
- impractical using only SNMP.
- 5. Guy Almes led a discussion of authentication. Consultation with
- members of the Security Area led to an agreement that a 16-byte
- Marker field per message would allow detection of spoofing.
- Prevention of spoofing seems to be beyond the ability of any
- application layered over available implementations of TCP. The
- presence of this 16-byte field, together with our provision of
- multiple authentication schemes, will allow very strong
- authentication. Having agreed on the need for supporting strong
- authentication and having modified the protocol to support it, we
- agreed that our needs in the near-term future were not great.
-
-
-
- 1
-
-
-
-
-
-
- ATTENDEES
- L. Allyson Brown allyson@umd5.umd.edu
- Guy Almes almes@rice.edu
- Isidro Castineyra isidro@bbn.com
- Steve Crumb scrumb@mot.com
- Robert Enger enger@sccgate.scc.com
- Dino Farinacci dino@esd.3com.com
- Dennis Ferguson dennis@gw.ccie.utoronto.ca
- Jeffrey Honig jch@tcgould.tn.cornell.edu
- Wendy Huntoon huntoon@a.pse.edu
- Peter Kirstein kirstein@cs.ucl.ac.uk
- Alex Koifman akoifman@bbn.com
- Kanchez Loa loa@sps.mot.com
- Yoni Malachi yoni@cs.stanford.edu
- C. Philip Wood cpw@lanl.gov
- Yakov Rekhter yakov@ibm.com
- Mike StJohns stjohns@umds.umd.edu
- Steve Storch sstorch@bbn.com
- Steven Willis swillis@wellfleet.com
-
-
-
- 2
-